Fix failed downloads being marked as downloaded, add rip repair - #1023

The problem

When a track fails to download twice, it gets logged to the failed-downloads database — and then marked as successfully downloaded.

Track.download() retried once and, on a second failure, called db.set_failed(...) but then returned normally. Media.rip() runs preprocess → download → postprocess unconditionally, so postprocess() went on to call db.set_downloaded(...). From that point on, PendingTrack.resolve() / PendingSingle.resolve() see the track in the downloads database and skip it, permanently. Re-running the same URL doesn't help, and it survives restarts. The only recovery is to find the missing tracks by hand.

I hit this on a real library. Of 629 rows in downloads.db, 18 were also present in failed_downloads.db — every single failed track had been recorded as downloaded.

The failures also leave truncated files behind. Because downloads always restart from byte 0 (BasicDownloadable opens the path "wb" and sends no Range header), a partial is never resumed — it just stays in the library as a file with correct tags and a plausible size that fails to decode partway through. I found 8 of these, silently unplayable past the truncation point.

There's a second, quieter version of the same bug: PendingTrack.resolve() has four failure paths and only one of them recorded anything. If the metadata request failed, if building metadata raised, or if fetching the downloadable URL failed, it logged a line and returned None — no file, no downloads row, nothing in the failed database. The track just went missing from the album with no trace anywhere. PendingSingle.resolve() had the same gap on three paths.

Finally, config.toml has always said "Then, rip repair can be called to retry the downloads", but no such command existed. The failed-downloads database was write-only — nothing ever read it back.

What this changes

Don't mark failed downloads as downloaded — raise TrackDownloadFailedError on persistent failure so Media.rip() stops before postprocess() and set_downloaded() is never reached for a track that failed. Also delete the partial file, since it can never be resumed. Album.download() and Playlist.download() already wrap each track.rip() in its own try/except and continue, so raising cannot abort a whole album or playlist.

Record tracks that fail while resolving — call set_failed() on the resolve paths that previously returned None silently, so those failures are retryable instead of invisible.

Add rip repair to retry failed downloads — implements the command config.toml already documents. It reads the failed database, retries each item through the normal pipeline, and clears the ones that succeed.

Two details worth flagging for review:

• Success is determined by membership in the downloads database, not by diffing the failed database before/after. Nothing in the pipeline removes rows from the failed database, so a before/after diff always reports zero repaired. Checking the downloads database is sound precisely because of the first commit: set_downloaded() is now only reachable from postprocess(), which a failed track never gets to.
• Repaired items are placed in their album's folder, because a failed item is usually one track missing from an otherwise complete album, and retrying resolves it as a single. --flat restores the old root-folder behaviour.

Interaction with #1009: that PR adds proper Range-based resumable downloads. If it lands, deleting the partial file here becomes actively wrong — it would throw away exactly the bytes #1009 wants to resume from. The deletion is only correct while downloads restart from byte 0, which is true on dev today. Happy to make the deletion conditional, drop it, or rebase on #1009, whichever the maintainers prefer. The rest of this PR is independent of that question.

Retrying through the album

Repair originally re-added each failed track by id, which resolves as a single. That builds album metadata from the track response — and on Tidal a track response carries almost nothing about its album:

album object keys: ['cover', 'id', 'title', 'vibrantColor', 'videoCover']

No track count, so tracktotal falls back to 1, and the artist is the track's artists rather than the album artist. Where folder_format uses {albumartist} or {tracktotal}, repaired tracks therefore land somewhere other than the album they belong to:

Simon Carter/Beautiful Destruction (2021) [MP4] ... [11 tracks]      the album
Simon Carter, Fabsi/Beautiful Destruction (2021) [FLAC] ... [1 tracks]

Running it against a real library produced 18 such folders holding 107 files.

It now looks up each failed track's album and retries through that. The metadata is then the album's own, so the folder, disc subfolders and cover art are all correct, and nothing extra is downloaded — tracks already in the downloads database are skipped, so only the missing ones are fetched. Albums are de-duplicated, so several failures from one album cost one retry rather than several. Anything whose album cannot be determined is still retried on its own.

Testing

• Drove a real Track.rip() against a downloadable that writes a partial file then raises, with temporary databases: confirmed it raises, logs to the failed database, does not mark downloaded, removes the partial, and leaves no stale progress-bar title.
• Ran rip repair against a real Qobuz account and recovered all 18 stuck tracks. Roughly half the large files hit genuine IncompleteRead errors along the way, which made a good test: on every pass the downloaded and failed databases stayed disjoint. Under the old code those would have become permanently lost tracks.
• Every commit compiles standalone.

Happy to split this further or adjust anything.